fix(sandbox): use Daytona code execution API - #175

Why

Production research PDF generation still returned Sandbox returned invalid artifact metadata after moving binary output out of stdout. Live sandbox diagnostics showed the deeper cause: the document renderer never executed. The custom runCode transport base64-encoded source into environment chunks and reconstructed it through a shell pipeline, but Daytona process execution did not inject those chunks, so Node received an empty program and exited successfully with no output.

What changed

• replace the custom base64/environment/shell reconstruction with Daytonas native /process/code-run` API
• map command and code environment variables to Daytonas documented envs` wire field
• preserve cwd explicitly for JavaScript and Python code execution
• preserve Python module semantics by compiling the original source after changing cwd
• retain bounded input validation, timeout behavior, audit records, usage metering, and provider error mapping
• remove the chunking constants and transport helpers entirely
• document the native code-execution boundary

Architecture / migration effects

• No database or migration changes
• No new dependency or deployment configuration
• Generated code is now sent as code over Daytona`s dedicated API instead of being disguised as shell environment data

Verification

• pnpm lint
• pnpm typecheck
• pnpm turbo build --force
• pnpm deadcode (passes; four existing Knip configuration hints remain)
• pnpm architecture:check
• pnpm turbo skills:build
• Live Daytona: 90,126-character JavaScript program executed with env and cwd intact
• Live Daytona: Python executed with env, cwd, and from __future__ semantics intact
• Live Daytona: full Markdown PDF renderer returned the artifact marker and created a valid 7,143-byte PDF file

Local verification used Node 26.4.0 while the repository pins Node 24.18.0; pnpm emitted the existing engine warning, and all checks passed.